Gremlinのカオスエンジニアリングを効果的に実践するための基礎コースで学んだことまとめ2 ~ リソース攻撃のユースケースとビジネスイニシアティブ ~

どうも、技術的・ビジネスイニシアティブについて基礎コースで学んだことをまとめた記事を投稿したものです。

今回は、同じく基礎コースで学べたGremlinでできるカオスエンジニアリングの攻撃タイプごとによるユースケース、ビジネスイニシアティブについてまとめていこうと思います。

Gremlinでは大きく3つの攻撃タイプに分けられています。

• リソース攻撃(Resource Attacks)
• 状態攻撃(State Attacks)
• ネットワーク攻撃　（Network Attacks）

以上の3つです。

本記事ではリソース攻撃について取り上げます。

リソース攻撃は、コンピューティングリソースの消費量の急激な変化に対するテストを行います。

リソース攻撃のユースケースとビジネスイニシアティブ

リソース攻撃の中には、4つのタイプの攻撃が存在しています。

CPU, Disk, IO, Memoryです。

CPU攻撃

CPU攻撃は、CPUの容量が制限されていたり、枯渇していても、アプリケーションが期待通りに動作することをテストします。

技術的なユースケース

• 負荷がかかった時の安定性とパフォーマンスの確保

　　私たちのシステムはCPUに負荷がかかっても動作を維持しなければいけませんが、重たい負荷を与える状況はCPU攻撃を用いることで重い負荷を再現できます。オンプレミスのデータセンターからパブリッククラウドの環境に移行する際にも有効です。

• Auto Scalingとアラートの仕組みの検証

　　クラウドプラットフォーム(AWSやAzureやGCP)のサービスだったり、オーケストレーションのツールは、設定に応じてアプリやシステムを自動でスケールアップできます。 そして監視ツールやアラートツールはキャパが減ると通知してくれます。

ただし、これらの閾値を決めるのはエンジニア次第となっています。CPU攻撃を行うことによって閾値に達した時にスケールするのか、アラートが通知されるのかを確認することができます。

• リソースクオータの検証

　　コンテナでは、リソースクォータによって、1つのコンテナで利用できるリソースが制限されます。 　　CPU攻撃を行うことにより、このクォータをテストしてリソースを使い切った時のアプリケーションの状態を把握することができます。

　　また、オーケストレーションツールが期待通りにクォータを実行しているかどうかも確認できます

ビジネスイニシアティブ

• ピーク時のトラフィックイベントに備える

　　CPU攻撃は、トラフィックが増えるイベント(ブラックフライデーとか)の状況をシミュレートすることができます。 　　このようなイベントでの影響を制御された環境で安全にシミュレートすることで、実際のイベント時に備えることができます。

• クラウドへの移行を効率化

　　クラウドへの移行を開始する前にCPU攻撃を行うことにより、共有インフラ上のノイズや、CPU能力が下がったインスタンスの状態をシミュレートできます。 以降作業を開始してから予想外の問題が発生することを防ぐことができます。

• 運用コストの削減

　　クラウド環境では本番トラフィックの予測に基づいてCPUキャパシティを過剰にしてしまいがちですが、CPU攻撃でさまざまなレベルのCPU下でのアプリケーションのパフォーマンスを測定できます。これによりキャパシティを調整できる情報を得ることになります。

　　また、オートスケーリングを検証することで、キャパシティをリアルタイムに調整することが可能になり、更なるコスト削減が期待できます。

Disk攻撃

Disk攻撃は、ストレージスペースが限られていたり、利用できない場合のシステムやアプリケーションの動作をテストし、動的なストレージプロビジョニングシステムを検証します

技術的なユースケース

• ディスクの容量とスループットのテスト

　　Disk攻撃は、復元されたバックアップ、複製されたデータベース、大規模なログファイルなど、大規模なデータセットの読み書きをシミュレートするためによく使用されます。　これによりワークロードを移行する前にディスク容量を確認できるだけでなく、ディスクスペースを埋めるプロセスがパフォーマンスにも影響を与えることも確認できます。

大量のデータを読み書きすると、ディスクのスループットが低下し、アプリケーションのスループットが低下する原因となるので、大規模なDisk攻撃は容量、スループット、および同時実行性を同時にテストすることができます

• 自動ディスククリーンアップ、圧縮、およびプロビジョニングのテスト

　　私たちはディスク容量を追加するためにいくつかの自動化されたメカニズムを使用します。 自動クリーンアップおよび圧縮ツール、シャーディング、ディスククォータシステムといったメカニズムをDisk攻撃によってテストし、期待通りに動作するかどうかを確認できます。

• モニタリングとアラートの仕組みの検証

　　他のリソースと同様に、私たちはディスクの使用状況を監視し、ディスク容量の不足による問題を回避する必要があります。 　　監視と閾値を設定し、適切にアラート通知を受け取れるのか、問題の対応が自動で行われるのかなどを確認します。

ビジネスイニシアティブ

• 運用コストの削減

　　クラウド環境では、高速で大容量のストレージは高価になりがちです。Disk攻撃で安価なストレージがワークロードに与える影響をシミュレートできるので、パフォーマンスを損なうことなくコスト削減ができる可能性があります。

• 障害発生のリスクを低減

　　ディスク容量の枯渇は予期せぬ障害を引き起こすことがあります。Disk攻撃でモニタリングやアラート機能を積極的にテストすることで、チームは重大なインシデントや停止の原因となるディスク使用量を排除できる可能性があります。

IO攻撃

IO攻撃は、重いIO操作のテストを行い、アプリケーションへの影響を把握することができます。

技術的なユースケース

• ストレージ移行の準備

  クラウド環境では高速なストレージは高価になりがちですが、クラウドへの移行はそういったソリューションソリューションへの移行を意味することが多いです。ストレージごとにIOPSが異なるので、アプリケーションのパフォーマンスにも影響します。

　　IO攻撃で、低速なストレージ状況のパフォーマンスをシミュレートすることにより、ユーザーに与える影響を測定し、移行を開始する前に高速なストレージのコストメリットを判断することができます。

• ディスクを多用するワークロードのテスト

　　データベースのように頻繁に、あるいは重いディスクアクセスを必要とするアプリケーションがありますが、重いIO操作は、CPUやRAMの使用率にも影響を与え、アプリケーションやシステムに意図しない副作用をもたらします。

　　IO攻撃によりこれらのアプリケーションや操作をシミュレートし、影響を観察することが可能です。

• キャッシュの有効性の検証

　　Redisなどのキャッシュは、メモリにデータを格納することでIOを削減しますが、 　　IO攻撃で基礎となるディスクに負荷をかけ、アプリケーションの応答性を測定することで、キャッシュの有効性を検証することができます。

　　IO攻撃はディスク障害は発生しませんが、使用可能なIOPSをすべて消費してディスクが応答しなくなることで、ディスクが使用できない状態をシミュレートできます。 　　これにより、ディスクにアクセスできなくなった時にキャッシュが有効に機能しているかどうかを確認できます。

ビジネスイニシアティブ

• ピーク時のトラフィックに備える

　　ブラックフライデーやサイバーマンデーのようなトラフィックのピーク時には、より多くのデータをディスクに書き込む必要があるのでスループットは低下します。 　　IO攻撃を実行することで、この影響をシミュレートし、本番環境でのピークに備えて準備ができます。

• エンドユーザーエクスペリエンスの向上

　　ディスクの待ち時間は、UXに影響を与えます。　IO攻撃中にアプリケーションのパフォーマンスをテストすることにより、レイテンシーのある箇所を特定して最適化することが可能です。

• 新製品の立ち上げを効率化

　　メディアストリーミングやファイル共有サービスのように、高いディスクスループットを必要とするサービスを立ち上げる準備にIO攻撃が役に立ちます。 サービスの利用が高い状況でも安定したパフォーマンスを提供しているかどうかの確認を行えます。

Memory攻撃

Memory攻撃は、システムのメモリ使用量をテストし、使用量が急激に増加しても耐えられるか、パフォーマンスを発揮できるかをテストします。

技術的なユースケース

• メモリリークとアウトオブメモリ（OOM）エラーに備える

　　Memory攻撃を行うことによりメモリを消費し、アプリケーションのパフォーマンスや可用性に大きな影響を与える可能性があるメモリリークやOOMエラーが発生した時の状況の確認して本番環境への準備を行えます

• メモリを大量に消費するワークロードのテスト

　　インメモリキャッシュ、データベース、機械学習モデルなど、本質的にメモリを大量に消費するワークロードでの確認が導入前に確認できます。 キャパシティプランニングやインフラの最適化に役に立ったりもします。

• クラウド移行の準備

　　CPU攻撃と同様に、Memory攻撃はAuto Scalingのしきい値の設定と検証、リソースクォータ（cgroupsやKubernetesのリソース制限など）の設定の検証、アラートのしきい値の検証など、クラウド移行の準備に役立ちます。

ビジネスイニシアティブ

• ピーク時のトラフィックに備える

  CPUと同様に、メモリ使用量もアクセスの増加に応じて変化します。ブラックフライデーやサイバーマンデーのようなトラフィックの多いイベントの前に、Memory攻撃を行うことで、このような状況をシミュレートし、準備をすることができます。

• 運用コストの削減

  CPUと同様に、Memory攻撃を行い、変化するメモリ環境下でのアプリケーションの安定性を検証し、より良い容量計画と潜在的なコスト削減が可能になります。

最後に

Gremlinのリソース攻撃における技術的なユースケースとビジネスイニシアティブに関して学んだことをまとめてみました。

例に挙げられているユースケースなどを自身のアプリケーションやシステムで当てはまるか確認し、カオスエンジニアリング実行の計画、目標を立てていきましょう。

次回は状態攻撃(State Attacks)に関することをまとめます。